Продолжаем вас знакомить с решением vGate R2 от компании Код Безопасности, предназначенным для защиты виртуальной инфраструктуры Hyper-V от несанкционированного доступа, а также для ее безопасной настройки средствами политик. В этой статье мы расскажем о том, как правильно настроить локальную сеть в соответствии с рефернсной архитектурой vGate, а также установить продукт с использованием различных конфигураций...

Как установить IP-параметры HP iLO через консоль сервера VMware ESXi.

При развертывании инфраструктуры VMware vSphere на базе серверов HP всегда требуется задать параметры IP-идентификации для интерфейса удаленной консоли iLO. Обычно это делается в настройках сервера, но удобнее сделать это из консоли ESXi, если вы используете кастомизированную сборку ESXi под HP (а ее надо использовать, так как некоторые девайсы могут просто не работать, поскольку в стандартной сборке под них нет драйверов).

Для начала откроем на хосте ESXi доступ по SSH в разделе Security Profile, стартовав соответствующий сервис:

Заходим на хост по SSH и переходим в папку с утилитами HP:

cd /opt/hp/tools

Копируем настройки HP iLO в файл XML:

./hponcfg -w ilo.xml

Далее этот файл нам нужно отредактировать, для этого можно использовать WinSCP или Veeam FastSCP.

Копируем iLO.xml к себе локально:

Открываем его в текстовом редакторе и правим секции, помеченные красным:

<!-- HPONCFG VERSION = "4.0-13.0" -->
<!-- Generated 11/11/2014 23:37:47 -->
<RIBCL VERSION="2.1">
<LOGIN USER_LOGIN="Administrator" PASSWORD="password">
<DIR_INFO MODE="write">
<MOD_DIR_CONFIG>
<DIR_AUTHENTICATION_ENABLED VALUE = "N"/>
<DIR_LOCAL_USER_ACCT VALUE = "Y"/>
<DIR_SERVER_ADDRESS VALUE = ""/>
<DIR_SERVER_PORT VALUE = "636"/>
<DIR_OBJECT_DN VALUE = ""/>
<DIR_OBJECT_PASSWORD VALUE = ""/>
<DIR_USER_CONTEXT_1 VALUE = ""/>
<DIR_USER_CONTEXT_2 VALUE = ""/>
<DIR_USER_CONTEXT_3 VALUE = ""/>
</MOD_DIR_CONFIG>
</DIR_INFO>
<RIB_INFO MODE="write">
<MOD_NETWORK_SETTINGS>
<SPEED_AUTOSELECT VALUE = "Y"/>
<NIC_SPEED VALUE = "100"/>
<FULL_DUPLEX VALUE = "N"/>
<IP_ADDRESS VALUE = "192.168.16.33"/>
<SUBNET_MASK VALUE = "255.255.255.0"/>
<GATEWAY_IP_ADDRESS VALUE = "192.168.16.254"/>
<DNS_NAME VALUE = "ESX01-iLO"/>
<PRIM_DNS_SERVER value = "192.168.16.1"/>
<DHCP_ENABLE VALUE = "N"/>
<DOMAIN_NAME VALUE = "educ.local"/>
<DHCP_GATEWAY VALUE = "Y"/>
<DHCP_DNS_SERVER VALUE = "Y"/>
<DHCP_STATIC_ROUTE VALUE = "Y"/>
<DHCP_WINS_SERVER VALUE = "Y"/>
<REG_WINS_SERVER VALUE = "Y"/>
<PRIM_WINS_SERVER value = "0.0.0.0"/>
<STATIC_ROUTE_1 DEST = "0.0.0.0" GATEWAY = "0.0.0.0"/>
<STATIC_ROUTE_2 DEST = "0.0.0.0" GATEWAY = "0.0.0.0"/>
<STATIC_ROUTE_3 DEST = "0.0.0.0" GATEWAY = "0.0.0.0"/>
</MOD_NETWORK_SETTINGS>
</RIB_INFO>
<USER_INFO MODE="write">
</USER_INFO>
</LOGIN>
</RIBCL>

Копируем измененный файл обратно на хост ESXi (предыдущий сохраните - просто переименуйте) и выполняем команду заливки конфигурации:

./hponcfg -f ILO.xml

Дождитесь успешного выполнения команды - и можно коннектиться к iLO через веб-браузер по новому адресу. Этот способ удобен тем, что можно не перезагружать сервер.

Многим администраторам виртуальной инфраструктуры VMware vSphere зачастую приходится перезапускать Management Network после различных операций с хостом VMware ESXi (например, чтобы обновить аренду IP-адреса у DHCP-сервера).

Делается это из консоли сервера ESXi (DCUI) в пункте меню "Restart Management Network":

Напомним, что доступ к графическому интерфейсу консоли сервера (DCUI) можно получить и по протоколу SSH, выполнив команду:

# dcui

Однако многие хотели бы рестартовать сеть ESXi консольной командой ESXCLI, которую можно выполнить, например, из vSphere Management Assistant. Для этого нужно просто отключить и включить сетевой интерфейс VMkernel на хосте. Делается это через пространство имен esxcli network.

При этом, поскольку вы подключены к ESXi через этот интерфейс, то нужно, чтобы две команды (отключение и включение) были выполнены обязательно вместе. Делается это добавлением точки с запятой (";") между командами.

Итак, узнаем имя интерфейса командой:

esxcli network ip interface ipv4 get

Далее отключаем и включаем интерфейс vmk0, что соответствует функции Restart Management Network в графическом интерфейсе хоста:

esxcli network ip interface set -e false -i vmk0; esxcli network ip interface set -e true -i vmk0

Компания VMware время от времени выпускает интересные постеры и диаграммы (кстати, они вывешены у нас в правой колонке чуть пониже), которые отражают различные процессы и описывают компоненты инфраструктуры VMware vSphere, View, vCloud и прочие. Не так давно был выпущен постер с портами и соединениями VMware vSphere 5.1, а на днях VMware выпустила аналогичный плакат с диаграммой портов "Network port diagram for Horizon View", который наглядно показывает взаимодействие компонентов, а заодно и дает информацию сетевым администраторам о том, какие правила нужно добавить в сетевой экран:

Там же, на страницах за постером, приведена таблица портов с пояснениями к используемым соединениям в инфраструктуре виртуальных ПК VMware View 5.2:

Нужная и полезная штука. Хотя с выходом VMware View 5.3 ее все же придется обновить, так как появятся новые компоненты (например, View Agent Direct Connection Plugin) или изменятся существующие (например, HTML Access).

На прошедшей конференции VMworld 2013 компания VMware представила свое виденье концепции ЦОД будущего - Software-Defined Datacenter, то есть датацентр, определяемый и направляемый программно, в котором слой оборудования полностью отделен от слоя программного обеспечения, а последний и реализует все необходимые сервисы пользователей и функции управления. То есть, оборудование - это просто подложка, элементы которой можно будет заменять, а все необходимые функции управления будут находиться на стороне программного обеспечения.

Выглядит это так:

В рамках этой концепции было объявлено о работе VMware в четырех направлениях:

• Расширение применения технологии виртуализации на все приложения (например, кластеры Hadoop).
• Трансформация хранилищ в абстрагированные и агрегированные дисковые ресурсы серверов (Virtual SAN) на базе разработок компании Virsto (с русскими корнями, кстати).
• Создание программно-определяемых сетей в датацентре на базе продукта VMware NSX, полученного после покупке компании Nicira.
• Повышение автоматизации датацентра и создание комплексных средств управления (таких как, например, решение VMware vCloud Automation Center (vCAC)).

Сегодня мы поговорим о третьем пункте - решении для построения виртуальной инфраструктуры сетей - VMware NSX, которое было анонсировано на VMworld как один из ключевых компонентов стратегии VMware в рамках концепции Software-defined networking (SDN).

VMware NSX - это решение полученное на основе двух продуктов: купленного Nicira NVP и собственного VMware vCloud Networking and Security (vCNS). Последний предназначен для комплексной защиты виртуального датацентра и построен на базе семейства продуктов VMware vShield. Решение VMware NSX предназначено для крупных компаний, которые планируют повысить степень гибкости сетевой среды датацентра, который связан с другими ЦОД компании, и где требуется переносить виртуальные машины между ними или поддерживать распределенную архитектуру кластеров.

Чтобы понять концепцию NSX можно провести аналогию с серверной виртуализацией, отмапив инфраструктуру VMware vSphere на инфраструктуру "гипервизора" NSX:

Такая архитектура, конечно же, требует интеграции с агентами в физическом оборудовании, которые уже есть в сетевых устройствах Arista, Brocade, Cumulus, Dell, HP и Juniper.

Сама же платформа VMware NSX включает в себя следующие компоненты:

• Controller Cluster - это система, состоящая из виртуальных или физических машин (как минимум 3), предназначенная для развертывания виртуальных сетей во всем датацентре. Эти машины работают в кластере высокой доступности и готовы принимать управляющие команды от различных средств через API, например, VMware vCloud или OpenStack. Кластер осуществляет управление объектами vSwitches и Gateways, которые реализуют функции виртуальных сетей. Он определяет топологию сети, анализирует поток трафика и принимает решения о конфигурации сетевых компонентов.
• Hypervisor vSwitches (NSX Virtual Switches)  - это виртуальные коммутаторы уровня ядра ESXi с программируемым стеком L2-L4 и конфигурационной базой. Они отвечают за работу с трафиком виртуальных машин, обеспечение туннелей VXLAN и получают команды от Controller Cluster.
• Gateways - это компоненты, предназначенные для сопряжения виртуальных и физических сетей. Они предоставляют сервисы IP routing, MPLS, NAT, Firewall, VPN, Load Balancing и многое другое.
• Ecosystem partners - партнеры могут интегрировать собственные виртуальные модули (Virtual Appliances) в инфраструктуру NSX на уровнях L4-L7. Подробнее об этом написано здесь.
• NSX Manager - это централизованное средство управления виртуальными сетями датацентра (с веб-консолью), которое взаимодействует с Controller Cluster.

Посмотрим на высокоуровневую архитектуру решения:

Как мы видим, NSX оперирует собственными виртуальными сетями, которые инкапсулируют в себе физические сети средствами протоколов STT, VXLAN и GRE (как это делается мы уже писали вот тут). А компонент NSX Gateway выполняет функции моста для коммутации на уровне L2 и маршрутизации на уровне L3.

В качестве серверных гипервизоров в инфраструктуре NSX могут быть использованы решения VMware vSphere, KVM или Xen.

Надо отметить, что есть два варианта развертывания решения:

• Окружение, состоящее только из хостов vSphere: в этом случае NSX опирается на инфраструктуру vSphere Distributed Switch (VDS) при взаимодействии с компонентами решения. А компонент NSX Gateway опирается на решение NSX Edge, которое было выделено из подпродукта vCNS Edge (бывший vShield Edge).
• Гибридное окружение с несколькими гипервизорами: тут NSX уже использует Open vSwitch для KVM и Xen, а также собственный виртуальный коммутатор NSX vSwitch, работающий на уровне ядра ESXi. С точки зрения шлюза тут уже NSX может использовать различные физические модули.

Вот так выглядит детальная архитектура решения VMware NSX с учетом развертывания в среде только с VMware vSphere (обратите внимание, что NSX может работать только с одним сервером vCenter - это ограничение архитектуры):

Тут видно, что на уровне гипервизора работают 4 компонента, так или иначе используемых NSX:

• Security - средства безопасности уровня ядра.
• Виртуальные сети VXLAN.
• Distributed Router (DR) - распределенный маршрутизатор.
• Distributed Firewall - распределенный сетевой экран, который мы упоминали вот тут.

А вот так выглядит решение NSX в гибридной среде с несколькими гипервизорами:

С точки зрения логических функций NSX выполняет следующее:

• Logical Switching - NSX использует комбинацию Stateless Transport Tunneling (STT), Generic Routing Encapsulation (GRE) и VXLAN для гибридных окружений или только VXLAN для окружений vSphere, чтобы предоставлять коммутацию уровня L2 вне зависимости от нижележащей топологии сети. Теперь все происходит на уровне эмулируемой структуры виртуальных сетей, не затрагивающей IP-адреса и не привязанной к физическому расположению, что значит, что виртуальную машину можно перемещать между датацентрами без изменения конфигурации сетей.

• Поддержка аппаратных туннелей - VXLAN Tunnel Endpoints (VTEPs), которые позволяют поддерживать технологию виртуальных сетей на аппаратном уровне и не создавать задержек в сети.
• Logical Routing - теперь L3-маршрутизация возможна на логическом уровне, вне зависимости от нижележащего оборудования и за счет наличия distributed routing (DR) module в VMware ESXi с поддержкой протоколов динамической маршрутизации BGP и OSPF.
• Logical Firewalling - эти возможности пришли из продукта  vCNS App (vShield App), они позволяют обеспечить комплексную защиту датацентра средствами модулей распределенного сетевого экрана (distributed firewall, DFW).
• Logical Load Balancing and VPN - эти функции были также взяты из vCNS и поддерживаются только для окружений vSphere. В этом случае компонент NSX Edge осуществляет балансировку соединений на уровне L7 с поддержкой различных алгоритмов, а также позволяет организовать надежный VPN-туннель к инфраструктуре на базе IPsec и SSL.

Более подробно о решении VMware NSX можно узнать на этой странице.

Как многие из вас знают, мы своевременно обновляем посты про диаграммы портов и соединений различных компонентов VMware vSphere и других продуктов компании. Об этом можно почитать, например, тут, тут и тут.

Недавно вышло очередное обновление схемы портов VMware vSphere 5.1. Схема уже является официальной и приведена в KB 2054806.

Приятно также и то, что теперь в этом же документе в виде таблицы приведены все порты различных компонентов VMware vSphere 5.x и назначение соединений:

25 июня компания ИТ-ГРАД предлагает принять участие в деловом завтраке, посвященном тематике сетевых устройств нового поколения. Запланированы выступления со стороны партнеров: Aruba Networks проведет обзор новейших решений в области мобилизации бизнеса (Wi-fi), а PaloAlto представит современные методы борьбы с угрозами уровня приложений и вредоносным кодом с помощью межсетевых экранов нового поколения.

«Традиционные средства безопасности не обеспечивают необходимый уровень визуализации, скорости изменений, контроля и защиты от современных угроз. Именно это стало толчком к созданию нового класса решений на рынке ИБ. Межсетевые экраны нового поколения (NGFW) позволяют безопасно развертывать и использовать приложения без ограничения потребностей бизнеса и ИТ-служб» (Дмитрий Рагушин, PaloAlto).

Участие в мероприятии бесплатное. Необходимо заранее зарегистрироваться в связи с ограниченным количеством мест (всего 17). В случае заинтересованности заполните форму, либо отправьте контактные данные на marketing@it-grad.ru - и присоединяйтесь к коллегам!

Место проведения: CleverСlub - специальное пространство для бизнес-профессионалов. Санкт-Петербург, ул. Кирочная, д. 9.

Те из вас, кто испытывает потребность в балансировке соединений в виртуальной инфраструктуре VMware vSphere, а также функциях безопасности, могут обратить свое внимание на продукт от Loadbalancer.org, поставляемый в виде виртуального модуля (Virtual Appliance).

Основные возможности продукта:

• Средства высокой доступности компонентов
• Полнофункциональная балансировка на уровнях 4/7
• Поддержка виртуальных и физических серверов
• Веб-консоль управления
• Функции HTTP Cookie Persistence
• Функции RDP Cookie Persistence
• Поддержка SSL Offloading
• Поддержка 802.1q VLAN
• Группировка интерфейсов 802.3ad Bonding
• Широкие возможности анализа пакетов
• Поддержка IPv6
• Поддержка SIP с функциями Call-ID Persistence

Виртуальный модуль может работать в трех режимах:

• Direct Routing (DR) - режим прямой маршрутизации
• Network Address Translation (NAT) - режим трансляции сетевых адресов
• Source Network Address Translation (SNAT) - режим трансляции исходного сетевого адреса

Более подробно с продуктом от Loadbalancer.org можно ознакомиться в следующих документах:

• Quick start guide
• Quick start guide VA
• Full admin guide
• Enterprise VA Product Sheet
• VMware View 5.0 Guide

Компания Microsoft недавно выпустила полезный постер "Networking in System Center Virtual Machine Manager 2012" для администраторов платформы Hyper-V.

Из постера вы узнаете о том, как:

• Планировать виртуальные сети в SC VMM 2012, используя логические представления сетей и виртуальных коммутаторов, включая VLAN, виртуализацию сетей, внешние сети и т.п.
• Настраивать сети в VMM для различных ролей в сетевой инфраструктуре предприятия.
• Понять объектную модель сетевого взаимодействия на примере приведенных в постере диаграмм.
• Расширить функциональность VMM за счет сторонних решений, а также соединить виртуальные сети виртуальных машин с внешними сетями через шлюз, балансировать запросы к ВМ и многое другое.

В общем, для сетевых администраторов в инфраструктуре виртуализации на базе Hyper-V - это мастрид.

Ну и немного полезных ссылок по сетевому взаимодействию в Hyper-V и SC VMM 2012:

• Using System Center 2012 SP1 – Virtual Machine Manager Logical Switch with Hyper-V
• Basic Hyper-V Networking in System Center 2012 SP1 – Virtual Machine Manager
• Networking in VMM Illustrated Overview
• A Different Perspective on VMM 2012 SP1 Networking
• Networking in VMM 2012 SP1 – Logical Networks (Part I)
• Virtual Networking in VMM 2012 SP1 – Part 1

Как многие из вас знают, в VMware vSphere 5.1 есть несколько типов трафика, которые могут быть переданы посредством интерфейса VMkernel (vmkX):

• Управляющий трафик клиентов (Management)
• Горячая миграция ВМ (vMotion)
• Трафик кластера непрерывной доступности (Fault Tolerance)
• Трафик репликации ВМ (Replication)

В vSphere Web Client эти типы трафика можно просто назначить интерфейсу vmk (VMkernel):

Но можно ли управлять этими настройками с помощью интерфейса ESXCLI? Оказывается, что, начиная с версии vSphere 5.1, это делается очень просто. Интерфейс vmk можно "тэгировать" различными типами трафика, что означает, что он будет их пропускать. В командной строки ESXCLI администратору доступно множество команд tag в следующем пространстве имен:

esxcli network ip interface

Как и с многими другими объектами, с тэгами можно совершать операции get, add и remove:

----------------------------------------------------------------------------------------------

vi-admin@vMA51:~> esxcli –server vcenter51 –vihost pod23-esx-01a.pml.local –username root network ip interface tag
Usage: esxcli network ip interface tag {cmd} [cmd options]

Available Commands:
add                  Adds a tag on a given VMkernel network interface.
get                   Gets the tags set on the given VMkernel network interface.
remove           Removes a tag on a given VMkernel network interface.

----------------------------------------------------------------------------------------------

Например, получить действующие тэги интерфейса vmk0 можно следующей командой:

vi-admin@vMA51:~> esxcli –server vcenter51 –vihost pod23-esx-01a.pml.local –username root network ip interface tag get -i vmk0
Tags: Management

Аналогично можно использовать действия add и remove. Таблица соответствия типов трафика VMkernel и их названий в виде тэгов:

За одну команду интерфейсу vmk можно поставить или снять только один тэг.

Не все знают, что в качестве распределенного коммутатора с расширенной функциональностью для инфраструктуры VMware vSphere существует не только устройство Cisco Nexus 1000V. Есть также и виртуальное устройство от IBM, которое называется System Networking Distributed Switch 5000V (DVS 5000V).

Это тоже программный распределенный коммутатор, который поставляется в виде 2 компонентов:

• Host Module (он же Data Path Module, DPM) - модуль, поставляемый в zip-формате (Offline Bundle) для хостов VMware ESXi 5.x, позволяющий контролировать состояние виртуальных коммутаторов в пределах хоста.
• Controller - виртуальный модуль (Virtual Appliance) в формате OVA, позволяющий централизованно управлять сетевой инфраструктурой виртуализации через хостовые модули.

vDS от IBM так же, как и Nexus 1000V, интегрирован с VMware vCenter и отображается как обычный Distributed Virtual Switch в интерфейсе vSphere Client. При этом он обладает следующими расширенными возможностями:

• Поддержка технологии Private VLAN для разделения трафика ВМ
• Поддержка списков контроля доступа (ACL) для контроля трафика ВМ
• Поддержка технологий зеркалирования портов (Port Mirroring): локально (SPAN) и удаленной (ERSPAN)
• Поддержка техники мониторинга трафика sFlow (похожа на NetFlow)
• Управление трафиком и статистика на базе стандарта IEEE 802.1Qbg (Edge Virtual Bridging, EVB)
• Поддержка технологий Static Port Aggregation и Dynamic Port Aggregation
• Поддержка логирования Syslog и по SNMP

С точки зрения управления таким распределенным коммутатором DVS 5000V оно построено на базе операционной системы IBM NOS (Network Operating System) и предоставляет следующие интерфейсы:

• Telnet
• SSH
• SNMP
• TACACS+
• RADIUS
• Интерфейс командной строки (CLI)

Более подробно о виртуальном модуле IBM DVS 5000V можно прочитать в даташите, а также в руководстве пользователя.

Мы уже писали о  полезных нововведениях, касающихся сетевого взаимодействия, доступных в распределенном коммутаторе VMware vSphere Distributed Switch (vDS), которые облегчают жизнь сетевым администраторам. В частности, рассмотрели механизм Netflow и его поддержку в vSphere 5.

Напомним, что посредством vDS доступны следующие новые возможности, которые описаны в документе "What's New in VMware vSphere 5.0 Networking":

• Поддержка Netflow версии 5 - возможность просмотра трафика между виртуальными машинами (ВМ-ВМ на одном или разных хостах, а также ВМ-физический сервер) посредством сторонних продуктов, поддерживающих Netflow.
• Поддержка зеркалирования портов Switch Port Analyzer (аналог технологии SPAN в коммутаторах Cisco) - возможность дублировать трафик виртуальной машины (а также VMkernel и физических адаптеров) на целевую машину (Port Mirroring), которая может реализовывать функционал системы обнаружения или предотвращения вторжений (IDS/IPS).
• Поддержка открытого стандарта Link Layer Discovery Protocol (LLDP, в реализации 802.1AB) - это механизм обнаружения соседних сетевых устройств и сбора информации о них для решения различных проблем сетевыми администраторами. Ранее поддерживался только протокол CDP (Cisco Discovery Protocol), поддержка которого есть не во всех устройствах.
• Улучшения механизма Network I/O Control - пулы ресурсов для сетевого трафика и поддержка стандарта 802.1q. Опредлеямые пользователем пулы для различных типов трафика позволяют приоритезировать и ограничивать пропускную способность канала для них посредством механизма shares и limits.

Сегодня мы рассмотрим поддержку открытого стандарта Link Layer Discovery Protocol (LLDP) (то есть, вендоронезависимого), который позволяет обнаруживать соседние с серверами ESXi коммутаторы и собирать о них информацию для последующего анализа.

Ранее можно было использовать только протокол CDP (Cisco Discovery Protocol), что сужало применение данной возможности. Теперь в настройках vDS у нас есть выбор LLDP или CDP:

По умолчанию, при создании распределенного коммутатора vDS, включен протокол CDP, поэтому для включения LLDP его надо переопределить в настройках. В поле Operation есть три режима работы:

• Listen - ESXi обнаруживают и отображают информацию о непосредственно подключенном физическом коммутаторе, но информация о самом vDS не предоставляется администратору физического коммутатора.
• Advertise - ESXi, наоборот, рассказывают о vDS физическому коммутатору, но не собирают информацию о нем.
• Both - обе предыдущих опции: vDS и физический коммутатор получают информацию друг о друге.

Чтобы посмотреть статистику, собранную с помощью LLDP, нужно нажать на синюю иконку с информацией для выбранного dvSwitch:

Эта информация позволяет проследить физическую коммутацию кабелей с хоста ESXi на порты физического коммутатора, без необходимости идти в серверную и смотреть, как там все подключено.

Источник: http://rickardnobel.se/archives/644.

Как известно, в VMware vSphere 5 появилось несколько полезных нововведений, касающихся сетевого взаимодействия, доступных в распределенном коммутаторе VMware vSphere Distributed Switch (vDS), которые облегчают жизнь сетевым администраторам. В частности, посредством dvSwitch доступны следующие новые возможности, которые описаны в документе "What's New in VMware vSphere 5.0 Networking":

• Поддержка Netflow версии 5 - возможность просмотра трафика между виртуальными машинами (ВМ-ВМ на одном или разных хостах, а также ВМ-физический сервер) посредством сторонних продуктов, поддерживающих Netflow.
• Поддержка зеркалирования портов Switch Port Analyzer (аналог технологии SPAN в коммутаторах Cisco) - возможность дублировать трафик виртуальной машины (а также VMkernel и физических адаптеров) на целевую машину (Port Mirroring), которая может реализовывать функционал системы обнаружения или предотвращения вторжений (IDS/IPS).
• Поддержка открытого стандарта Link Layer Discovery Protocol (LLDP, в реализации 802.1AB) - это механизм обнаружения соседних сетевых устройств и сбора информации о них для решения различных проблем сетевыми администраторами. Ранее поддерживался только протокол CDP (Cisco Discovery Protocol), поддержка которого есть не во всех устройствах.
• Улучшения механизма Network I/O Control - пулы ресурсов для сетевого трафика и поддержка стандарта 802.1q. Опредлеямые пользователем пулы для различных типов трафика позволяют приоритезировать и ограничивать пропускную способность канала для них посредством механизма shares и limits.

Все эти новые возможности мы разберем в следующих заметках, а сегодня сосредоточимся на механизме Netflow и его поддержке в vSphere 5. NetFlow — сетевой протокол, предназначенный для учёта сетевого трафика, разработанный компанией Cisco Systems. Является фактическим промышленным стандартом и поддерживается не только оборудованием Cisco, но и многими другими устройствами.

Для сбора информации о трафике по протоколу NetFlow требуются следующие компоненты:

• Сенсор. Собирает статистику по проходящему через него трафику. Обычно это L3-коммутатор или маршрутизатор, хотя можно использовать и отдельно стоящие сенсоры, получающие данные путем зеркалирования порта коммутатора. В нашем случае это распределенный коммутатор vDS.
• Коллектор. Собирает получаемые от сенсора данные и помещает их в хранилище.
• Анализатор. Анализирует собранные коллектором данные и формирует пригодные для чтения человеком отчёты (часто в виде графиков).

NetFlow дает возможность сетевому администратору мониторить сетевые взаимодействия виртуальных машин для дальнейших действий по обнаружению сетевых вторжений, отслеживания соответствия конфигураций сетевых служб и анализа в целом. Кроме того, данная возможность полезна тогда, когда требуется отслеживать поток трафика от приложений внутри виртуальной машины с целью контроля производительности сети и целевого использования трафика.

Синяя линия на картинке показывает настроенный виртуальный коммутатор, который посылает данные Netflow на стороннюю машину (коллектор), которая подключена к хост-серверу VMware ESXi через физический коммутатор. Коллектор уже передает данные анализатору. Netflow может быть включен на уровне отдельной группы портов (dvPortGroup), отдельного порта или аплинка (Uplink).

Для начала настройки Netflow нужно зайти в свойства коммутатора vDS (он должен быть версии 5.0.0 или выше):

Здесь мы указываем IP-адрес коллектора, куда будут отправляться данные, его порт, а также единый IP-адрес коммутатора vDS, чтобы хосты не представлялись отдельными коммутаторами для коллектора.

Включить мониторинг Netflow можно в свойствах группы портов на vDS в разделе Monitoring:

Далее в эту группу портов включаем одну из виртуальных машин:

Теперь можно использовать один из продуктов для сбора и анализа трафика Netflow, например, Manage Engine Netflow Analyzer. Пример статистики, которую собирает этот продукт по протоколам (в данном случае большинство трафика - http):

Netflow можно использовать для различных целей мониторинга, например, в инфраструктуре VMware View, где присутствуют сотни виртуальных машин, можно сгруппировать трафик по группам и смотреть, сколько трафика выжирается видеосервисами (Youtube, к примеру), так как это может сильно влиять на производительность сети в целом:

Применений Neflow на самом деле уйма, поэтому его поддержка в VMware vSphere 5 может оказаться вам очень полезной.

Раньше блоггеры публиковали диаграммы портов и соединений для VMware vSphere и других продуктов по отдельности, о которых мы писали тут и тут. Для VMware vSphere 5 список портов стал настолько обширен (из-за увеличения количества компонентов), что блоггеры уже перестали рисовать картинки и диаграммы.

Напомним, что последнюю версию схемы портов для VMware vSphere 4.1 можно скачать вот тут:

Теперь же сетевым администраторам и администраторам ИБ нужно запомнить вот эту ссылку на статью: KB 1012382, где приведены порты, используемые не только VMware vSphere 5, но и другими продуктами VMware: View, SRM, Converter и пр. Там в таблице конечно мешанина, но ничего другого пока нет:

Для каждого порта приведены комментарии - зачем он нужен и когда используется. Обратите внимание, что порты для vSphere Client указаны внизу статьи.

Как вы знаете, компания Код Безопасности, выпускающая продукт номер 1 для защиты виртуальных сред vGate R2 (читаем тут и тут), выпускает еще несколько программных и аппаратных решений для защиты физической и виртуальной инфраструктуры (см., например, тут).

Один из таких продуктов, интересных вам - это Security Code TrustAccess, который позволяет организовать распределенный межсетевой экран (МЭ) с централизованным управлением, предназначенный для защиты серверов и рабочих станций локальной сети от несанкционированного доступа и разграничения сетевого доступа к информационным системам предприятия, в том числе в инфраструктурах виртуализации (а также трафика между машинами в рамках одного хост-сервера).

Надо сказать, что TrustAccess - это один из тех продуктов, которые позволят защитить виртуальную инфраструктуру vSphere, в которой обрабатываются персональные данные, согласно требованиям закона ФЗ 152. То есть его можно и нужно использовать совместно с продуктом vGate.

Чтобы понять как все это делать, приходите на вебинар "Защита виртуальных машин от сетевых угроз с помощью межсетевого экрана TrustAccess", который пройдет 30 ноября в 11:00 по московскому времени:

Многие из вас используют продукт номер 1 для создания отказоустойчивых хранилищ StarWind Enterprise, позволяющий предоставлять общие хранилища для виртуальных машин через iSCSI. Это очень хорошая технология для небольших компаний и филиалов, использующих VMware vSphere, но не могущих себе позволить полноценную систему хранения с дублированными аппаратными компонентами. Напомним, что скоро продукт будет доступен для двухузловой конфигурации Microsoft Hyper-V, а также выйдет версия StarWind 5.8, где обещают еще больше нововведений.

Некоторые пользователи применяют доступ к таргетам iSCSI для StarWind изнутри виртуальных машин (например, можно использовать бесплатное издание StarWind). Однако с VMware vSphere 5 и адаптером vmxnet3 обнаружилась интересная проблема - согласно KB 2006277, драйвер vmxnet3 из комплекта vSphere 5 некорректно работает с большими кадрами Jumbo Frames. Это приводит к деградации производительности и потере сетевого соединения.

Какие есть выходы:

• Использовать драйвер vmxnet3 из комплекта VMware Tools для версии vSphere 4.x (можно загрузить тут)
• Использовать виртуальный сетевой адаптер vmxnet2 (Enhanced) или E1000 из комплекта vSphere 5

Надо отметить, что при соединении серверов ESXi 5 с хранилищами StarWind с настроенными Jumbo Frames полностью поддерживается. Также все работает и в конфигурации с томами RDM для виртуальных машин в режиме физической и виртуальной совместимости.

Компания VMware работает над решением проблемы для адаптера vmxnet3 и Jumbo Frames при работе из гостевой ОС. Спасибо Константину Введенскому за новость.

Мы уже писали о новом продукте VMware vSphere Storage Appliance (VSA), который позволяет создать кластер хранилищ на базе трех серверов (3 хоста ESXi 5 или 2 хоста ESXi 5 + физ. хост vCenter), а также о его некоторых особенностях. Сегодня мы рассмотрим, как работает кластер VMware VSA, и как он реагирует на пропадание сети на хосте (например, поломка адаптеров) для сети синхронизации VSA (то есть та, где идет зеркалирование виртуальных хранилищ).

На проходящей конференции VMworld 2011 в Лас-Вегасе за прошедший день было сделано несколько интересных анонсов. Три из них кажутся наиболее важными.

1. Проект VMware Appblast.

Это новый проект VMware, который позволит открывать виртуализованные с помощью ThinApp приложения в любом веб-браузере, совместимом с HTML 5 и Java. Совместно с VMware Horizon App Manager, технология VMware Appblast позволит организовать доставку приложений упакованных ThinApp на любое устройство пользователя, включая планшеты iPad или коммуникаторы на базе Android.

2. Технология сетевого взаимодействия VXLAN (Virtual eXtensible LAN).

Это уровень абстракции Layer 2 для доступа к виртуальным машинам вне зависимости от их расположения. Технология, разработанная совместно с компанией Cisco, использует технологию инкапсуляции "MAC-in-UDP" для создания схемы взаимодействия виртуальных машин, которые могут перемещаться между разными датацентрами со своими физическими сетями и адресацией. В случае применения VXLAN ничего не нужно будет менять с точки зрения сетевой идентификации ВМ в случае ее перезда, например, в другой датацентр (к примеру, сервис-провайдера).

Более подробно о VXLAN вы можете прочитать здесь.

3. Проект VMware Octopus.

Многие знают, что такое сервис Dropbox. Это облачное хранилище данных, но относительно которого есть сомнения в надежности и безопасности. VMware Octopus - это некий аналог Dropbox, т.е. онлайн-хранилище данных, которое позволит крупным предприятиям организовать облачное хранение данных с необходимым уровнем доступности, надежности и безопасности.

У этого проекта есть веб-сайт, на котором можно зарегистрироваться для раннего участия в бете сервиса. Более подробно про проект написано тут.

Скоро об этом обо всем - подробнее.

Компания VMware в июле 2011 года объявила о доступности новых версий целой линейки своих продуктов для облачных вычислений, среди которых находится самая технологически зрелая на сегодняшний день платформа виртуализации VMware vSphere 5.0.

Мы уже рассказывали об основном наборе новых возможностей VMware vSphere 5.0 неофициально, но сейчас ограничения на распространение информации сняты, и мы можем вполне официально рассказать о том, что нового для пользователей дает vSphere 5.

Некоторым из вас должен быть знаком проект pfSense, который представляет собой разработку программного фаервола и роутера на базе дистрибутива FreeBSD. Это средство есть также в виде виртуального модуля (Virtual Appliance), которое можно импортировать в VMware vSphere в качестве уже готовой машины. Также Eric Sloof сделал его в в формате OVA.

Естественно, pfSense - это бесплатно и open source. Для продукта доступно огромное количество модулей, за счет которых можно расширять функционал.

Как вы знаете, есть такой хороший продукт vGate 2, который производится нашим спонсором - компанией "Код Безопасности" (об основных его возможностях можно почитать в нашей статье). Нужен он для двух важных с точки зрения информационной безопасности вещей: защиты компонентов VMware vSphere от несанкционированного доступа (НСД) и автоматической настройки среды VMware vSphere (хосты ESX и виртуальные машины) в соответствии со стандартами и регламентами по обеспечению безопасности виртуальных инфраструктур (это экономит деньги, которые вы должны были бы потратить на консультантов, обучение своих специалистов и ручную настройку виртуальной среды).

Кстати, важная новость. Вышел vGate 2 с полной поддержкой VMware ESXi 4.1 (об этом мы писали тут, но продукт был еще в бете). Скачать vGate 2 для VMware ESXi можно тут.

Но сегодня мы поговорим о том, как было бы неплохо организовать безопасную инфраструктуру доступа системных администраторов VMware vSphere к различным компонентам среды виртуализации. Это нужно для того, чтобы понимать как правильно наладить контроль за серверами ESX / ESXi и виртуальными машинами со стороны vGate, а также разграничить доступ к этим объектам в рамках зон ответственности администраторов vSphere.

Логичной выглядит следующая схема построения локальной сети в контексте доступа к компонентам виртуальной инфраструктуры:

Немного опишем ее:

• Выделяем на уровне домена безопасности отдельно сеть администрирования инфраструктуры vSphere. Она содержит серверы ESX / ESXi, сервер vCenter, а также сервер авторизации vGate. Сам сервер авторизации имеет два сетевых адаптера - одним он смотрит в сети администрирования vSphere, а другим во внешнюю сеть предприятия, где находятся рабочие станции администраторов. Таким образом из последней сети в сеть управления можно попасть исключительно через сервер авторизации vGate (компоненты vGate выделены зеленым). На рабочих местах администраторов vSphere и администратора ИБ также установлены клиентские компоненты vGate.
• В отдельную подсеть нужно выделить сеть репликации ВМ (та, что для vMotion и Fault Tolerance).
• В отдельную подсеть выделяем сеть для IP-хранилищ (NFS/iSCSI).
• Ну и, само собой, сеть виртуальных машин тоже должна быть отдельной. Разделение сетей на хостах ESX / ESXi лучше делать на базе тегирования на уровне виртуального коммутатора (см. виды тэгирования).

Если взглянуть на разделение сетей со стороны сетевых адаптеров хост-сервера ESX сервера авторизации vGate, мы получим такую картину:

После конфигурирования локальной сети обязательно следует настроить маршрутизацию между подсетями, а также убедиться в наличии доступа с рабочих мест администраторов vSphere к элементам управления виртуальной инфраструктурой (vCenter и хост-серверы).

Вот основные варианты настройки маршрутизации (АВИ - это администратор виртуальной инфраструктуры):

Вот собственно и основные правила.

Как вы знаете, в механизме высокой доступности VMware High Availability (HA) есть такая настройка как Isolation Responce, которая определяет, какое событие следует выполнить хосту VMware ESX / ESXi в случае наступления события изоляции для него в кластере (когда он не получает сигналов доступности - Heartbeats - от других хост-серверов).

• Leave powered on
• Power off
• Shutdown

Сделано это для того, чтобы вы могли выбрать наиболее вероятное событие в вашей инфраструктуре:

• Если наиболее вероятно что хост ESX отвалится от общей сети, но сохранит коммуникацию с системой хранения, то лучше выставить Power off или Shutdown, чтобы он мог погасить виртуальную машину, а остальные хосты перезапустили бы его машину с общего хранилища после очистки локов на томе VMFS или NFS (вот кстати, что происходит при отваливании хранища).
• Если вы думаете, что наиболее вероятно, что выйдет из строя сеть сигналов доступности (например, в ней нет избыточности), а сеть виртуальных машин будет функционировать правильно (там несколько адаптеров) - ставьте Leave powered on.

Но есть еще один момент. Как вам известно, VMware HA тесно интегрирована с технологией VMware Fault Tolerance (непрерывная доступность ВМ, даже в случае выхода физического сервера из строя). Суть интеграции такова - если хост с основной виртуальной машиной выходит из строя, то резервный хост выводит работающую резервную ВМ на себе "из тени" (она становится основной), а VMware HA презапускает копию этой машины на одном из оставшихся хостов, которая становится резервной.

Так вот настройка Isolation Responce не применяется к машинам, защищенным с помощью Fault Tolearance. То есть, если хост VMware ESX с такой машиной становится изолированным, при настройке Power off или Shutdown он такую машину не гасит, а всегда оставляет включенной.

Рекомендация - иметь network redundancy для сети heartbeats. Не должен хост себя чувствовать изолированным, если он весь не сломался.

Несколько дней назад компания Citrix объявила о выходе очередного обновления Feature Pack 1 своей платформы виртуализации XenServer 5.6. Этот релиз имеет множество новых интересных возможностей, наиболее важной из которых является возможность использования виртуального распределенного коммутатора (в том числе и на базе Open vSwitch).

Список новых возможностей Citrix XenServer 5.6 Feature Pack 1:

• Distributed Virtual Switching.  Эта возможность позволяет использовать средства управления распределенным сетевым взаимодействием хост-серверов и виртуальных машин (например, cross-host private networks - аналог PVLAN на dvSwitch в VMware vSphere). Также поддерживается устройство Open vSwitch (OVS) для хостов XenServer hosts, а также компонент Controller для управления несколькими vSwitches (сам Controller есть только в издании Premium). Open vSwitch включает в себя поддержку больших кадров Jumbo Frames, позволяющих добиться наибольшей производительности в сетях хранения на базе iSCSI. При этом Open vSwitch пока не поддерживает агрегацию каналов (Link Aggregation).
• VM Protection & Recovery - использование снятия мнгновенных снимков (снапшотов) и экспорта виртуальных машин по расписанию. Новая версия XenServer включает в себя простую утилиту для бэкапа виртуальных машин и их восстановления (из снапшота). При этом дифференциальные снапшоты не поддерживаются (будет в следующих версиях). В бесплатной версии этой функциональности нет.
• Web Self-Service. Портал самообслуживания для пользователей виртуальных машин на основе привилегий, определенных администратором. Создание машин прямо из портала пока не поддерживается (будет потом).
• Boot from SAN with multi-pathing support.  Возможность загрузки хостов XenServer через HBA-адаптер Fibre channel из сети SAN.
• HA Restart Priority. Возможность настройки политик механизма отказоустойчивости таким образом, чтобы расставить приоритеты по старту виртуальных машин отказавшего хост-сервера (например, для вспомогательных ВМ StorageLink Gateway VM или Distributed vSwitch Controller VM, которые должны запуститься сначала).
• Improved XenDesktop VDI scalability. Улучшения под виртуализацию настольных ПК (VDI) - увеличение коэффициента консолидации виртуальных машин на хост-серверах посредством использования компонентом control domain (Dom0) нескольких процессоров и других улучшений.
• Enhanced XenCenter. Улучшенные средства управления XenCenter, включая полностью конфигурируемый StorageLink, отчетность об использовании ВМ и даже возможности подсчета затрат на виртуальную инфраструктуру (chargeback).
• Improved MPP RDAC multi-pathing - отчетность о статусе пути в конфигурации с несоколькими путями к СХД, а также отчетность и возможность срабатывания оповещений (health reporting and alerting).
• Snapshot improvements. После удаления снапшота - на системе хранения все аккуратно подчищается.
• Enhanced guest OS support - лучше работают: Windows 7 SP1, Windows Server 2008 R2 SP1, RHEL 6.0 (RTM), CentOS 6.0 (RTM), Oracle Enterprise Linux 6.0 (RTM), Debian Squeeze (32 and 64-bit) и SLES 11 SP1.
• Generic RHEL 5.x support. RHEL / CentOS / Oracle Enterprise Linux 5.0- 5.5 support with a generic "RHEL 5" template.
• Драйверы Brocade HBA - а также утилиты командной строки включены в XenServer.
• Provisioning Services Improvements. Есть поддержка Windows volume license (MAK и KMS) при развертывании виртуальных машин.
• XenDesktop platform enhancements. Технология локального кэширования образов виртуальных машин для экономии дискового пространства в инфраструктуре виртуальных ПК (VDI). Будет использоваться в следующей версии Citrix XenDesktop.

Скачать Citrix XenServer 5.6 FP1 (включая бесплатную версию) можно по этой ссылке.

На днях компания Citrix сделала доступным бесплатное средство для мониторинга производительности хост-серверов виртуализации Citrix XenServer Virtual Machine Performance Utility.

Данное ПО поставляется в виде виртуальной машины для развертывания на XenServer, которая позволяет отслеживать производительность сетевого взаимодействия и работу виртуальных машин с хранилищами (storage I/O и network I/O). Через веб-интерфейс можно получить информацию о следующих аспектах производительности:

Disk I/O performance utility - предоставляет следующую информацию: sequential read/writes и random read/writes с различными размерами блоков.

Network I/O performance utility - это модифицированная версия утилиты netperf. Позволяет мониторить пропускную способность сети и задержки.

Скачать Citrix XenServer Virtual Machine Performance Utility можно по этой ссылке.

Компания 5nine, известная своим программным обеспечениям для платформы виртуализации Hyper-V, выпустила вторую версию продукта Virtual Firewall 2.0 for Hyper-V. Этот продукт позволяет организовать виртуальный сетевой экран в инфраструктуре виртуальных машин.

Возможности продукта:

• Controls Network Traffic – используя скрипты PowerShell API или в GUI, администратор может определить различные правила фаервола для различных типов траффика, идущего к сети виртуальных машин серверов Hyper-V, а также в сети между виртуальными машинами, что позволяет организовать защиту от внешних и внутренних угроз.
• Security Heartbeat Service – сервис, позволяющий в реальном времени проверять правила фаервола, и, если происходит подозрительная активность со стороны виртуальной машины, может выключить или приостановить данную ВМ.
• Deployment options – 5nine Virtual Firewall может быть использован совместно с Microsoft System Center Virtual Machine Manager для виртуальных машин, а также для физических серверов перед P2V-миграцией.
• Compliance Audits – возможность проведения аудита (отчеты) на соответствие политикам безопасности траффика в виртуальной инфраструктуре.

Скачать 5nine Virtual Firewall for Hyper-V можно по этой ссылке.

Бывает так, что необходимо регламентировать процедуру тестирования отказоустойчивости сетевых интерфейсов VMware ESX (NIC Teaming). В этом случае проверку Network Failover Maish Saidel-Keesing предлагает проводить так:

1. Отключаем один из физических NICs сервера VMware ESX для которого настроен Failover Order, переводя его в режим "10 Half-Duplex ":

[root@esx1 ~]#esxcfg-nics -s 10 -d half vmnic2

2. Видим, что интерфейс отключился:

3. Перед этим запускаем пинги из виртуальной машины, где наблюдаем их потерю из-за "отказа" сетевого адаптера ESX. Потом соединение должно восстановиться по резервному NIC сервера ESX:

4. Включаем интерфейс, переводя его в режим Auto Negotiate:

[root@esx1 ~]# esxcfg-nics -a vmnic2

Если у вас есть 2 виртуальные машины на платформе VMware vSphere / ESX, но они находятся на разных виртуальных коммутаторах (vSwitch) и в разных сетях, то просто передать между ними (или на них) файлы по сети не получится. Здесь на помощь приходит смекалка:

1. Можно создать ISO-образ с необходимыми файлами и положить его на общее хранилище VMFS. Затем можно монтировать этот ISO-образ к той виртуальной машине, на которую необходимо скопировать файлы.

2. Можно подцепить к виртуальной машине VMDK-диск, на который залить нужные файлы, затем этот vmdk можно будет отцепить от первой виртуальной машины и подцеплять к другим ВМ. Помните, что Hot Add виртуального диска в VMware vSphere есть, а вот Hot Remove - не работает, надо будет останавливать виртуальную машину.

3. Можно создать новую виртуальную машину с двумя виртуальными сетевыми интерфейсами (vNIC), один из которых будет "смотреть" в Network одной виртуальной машины, а другой vNIC, соответственно - в Network другой (по-сути роутер).